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Abstract- Elliptic curve cryptography (ECC) will be an important technology for electronic privacy and authen- 
tication in the near future. There are many published specifications for elliptic curve cryptosystems, most of which 
contain detailed descriptions of the process for the selection of domain parameters. Selecting strong domain parame- 
ters ensures that the cryptosystem is robust to attacks. Due to a limitation in several published algorithms for doubling 
points on elliptic curves, some ECC implementations may produce incorrect, inconsistent, and incompatible results if 
domain parameters are not carefully chosen under a criterion that we describe. Few documents specify the addition or 
doubling of points in such a manner as to avoid this problematic situation. The safety criterion we present is not listed 
in any ECC specification we are aware of, although several other guidelines for domain selection are discussed in the 
literature. We provide a simple example of how a set of domain parameters not meeting this criterion can produce 
catastrophic results, and outline a simple means of testing curve parameters for interoperable safety over doubling. 


1 Introduction 

Elliptic curve cryptography (ECC) appeal's to be emerging as a technology of choice for key transport and 
agreement in cryptosystems. ECC can be used to implement public key sytems that offer advantages in 
both smaller key length and faster computation time over traditional public key systems like RSA and DSA. 
ECC techniques can also be used to exchange shared secret keys for traditional symmetric cryptographic 
algorithms like AES or triple-DES. Government and fi nancial industries in the United States have begun the 
slow process of adopting ECC in their systems. 

The major advantage that ECC has over RSA and DSA is that the lengths of ECC keys scale linearly with 
those of AES keys of equivalent strength. For example the security of 256 bit AES keys is equivalent to that 
of 512 bit ECC keys, while it takes RSA keys of 15,360 bits to rival this strength. Keys of this length take 
up a considerably disproportionate amount of storage space and capacity for transmission in comparison to 
the security level they provide. Operations using keys of that length are also terribly expensive for smaller 
mobile and wireless hosts of limited power and computational resources. 

The basic building blocks of ECC systems are points on curves whose coordinates are members of a 
number-theoretic fi eld. The two fi elds typically employed are If„ and TV™. . Elements of F p are integers from 
0 to some prime p and the fi eld operations of addition and multiplication are performed modulo p. Elements 
of F- 2 '" are binary strings of length m and operations are performed bitwise across the fi eld elements. 

Several standards bodies have produced exact descriptions of the fi elds F p and Fym . , along with tech- 
niques for working with curves over points whose coordinates are fi eld members (for example ANSI [X9.62, 
X9.63], IEEE [P1363], NIST [FIPS 186-2], and SECG [SEC 1]). These base standards are implemented in 
commercial products and used in communications protocols (by the IETF, for example [GBWM + 04]) to 
provide cryptographic functions. 
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We describe a glaring om mi sion from many ECC-explanatory documents and some of the standards, 
that affects the selection of domain parameters for ECC. Many of the algorithms presented for doubling 
points arc not able to function for certain points on the axes and thus implementations may either fail or 
produce incorrect results if those points arc members of a selected domain and arc encountered in some 
calculation. We present one example of parameters that can generate an error condition, and show how it 
results in a failed Diffi e-Hellman key exchange. In addition to revising some of the standards to properly 
specify the doubling operation, we make the recommendation that those selecting curves for use in practice 
make explicit efforts to avoid using domain parameters that can create possible error situations. 

2 Problem Description 

Equation 1 is used to specify the points on an elliptic curve over fi eld F p with domain parameters a and b 
chosen from F p , where each point’s coordinates, x and y, arc also elements of F p . 

y 2 = x 3 + ax + b ( 1 ) 

Geometrically, addition of two points, (xi, 2/1) and (x 2 . y 2 ), on such a curve is accomplished by drawing 
a line through both points. This line will intersect the curve at some other point with coordinates (x 3, 7/3). 
The additive inverse of this point, (x 3 , —2/3), is the desired sum. To double a point on a curve (add it to 
itself), the same proceedure is performed, except since it is not possible to defi ne a line with a single point, 
instead a line tangent to the curve at the point to be doubled is used. With curves over F p and F-> m where 
coordinates arc discrete fi eld elements and the shape of a curve is not easily visualized, a numeric method is 
employed for adding and doubling points. The rules for adding and doubling points arc clearly specifi ed in 
many of the ECC standards. 

For points (xi, 2/1) and (x2, 2/2) on a curve over F p , their sum, (x 3 . y 3 ) is given by equation 2 , where all 
operations are done modulo p. 


(>3, 2/3) = (A 2 - x\ - x 2 , A(xi - x 3 ) - 2/1) ( 2 ) 

For two distinct points, A simply represents the slope between them and is given by equation 3 , while 
when doubling a point (x\ = x 2 and 2/1 = yi), A represents the slope of a tangent to the curve at that point 
and is given by equation 4 . Using these equations to compute A, fractions arc evaluated using multiplication 
modulo p of of the numerator by the multiplicative inverse of the denomator in F p . 


2/2 ~ 2/1 
x 2 - Xl 
3x 2 + a 
22/1 


( 3 ) 

( 4 ) 


These defi nitions of A arc always accompanied in the literature by two restrictions. Since equation 1 
only contains the term y 2 in the 2/-coordinate, no more than two points exist with the same x-coordinate. 
Thus, the fi rst restriction is that if adding two distinct points such that xi = x 2 , then 2/1 = — 2/2(mod p), so 
the points are additive inverses and their sum is ( 0 , 0 ). This intuitively makes since, as a line between the 
points would lie perpendicular to the x-axis and never be able to intersect another point on the curve. In 
this case, the normal addition rules arc short-circuited and the point ( 0 , 0 ), which is, by defi nition, present 
on every curve, is returned. The second restriction is that for doubling a point, the 2/-coordinate must not be 
0 . In many stadards, no algorithm is given for doubling points that lie on the x-axis. At least one standard 
[P 1363 ] specifi es that the double of such a point yeilds ( 0 , 0 ), however several other documents ignore this 
situation, and present no information on how it is to be handled. 
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The situation is si mi lar for elliptic curves over . Such curves arc defi ned by the parameters m, a, 
and 6, where m is the length in bits of each fi eld element, and a and b set the curve’s shape according to 
equation 5. 


y 2 + xy = x 3 + ax 2 + b (5) 

In the case of such curves over F yn, doubling a point {x\,y\) into the point (x.-j. y:>) is accomplished 
via equation 6 with A given by equation 7. Field addition is done using exclusive-or on the bit strings and 
fi eld multiplication yielding an m bit string whose value depends on the basis used 1 . 


(^ 3 , 2 / 3 ) = (A 2 + A + a, x\ + (\ + l)x 3 ) (6) 

A = x\ + — (7) 

x\ 

In the case of equation 7, to avoid a denominator of 0, the point may not lie on the y-axis, or n / 0 m . 
In some documents, the algorithm's output is unspecifi ed if this condition is not met, although at least one 
[P1363] properly returns (0, 0) in such cases. 

Both curves in F p and those in Fym may contain points for which the doubling operation is unspecifi ed. 
This is evident, yet not addressed in some of the ECC standards. One of the standards [X9.63] even uses an 
example curve containing such a point. The curve over F p with p = 23, a = 1, and 6 = 1 contains the point 

(4, 0). This is clearly on the curve as 0 2 = 0 = 0(mod23), and 4 3 + 1(4) + 1 = 69 = 0(mod23), yet the 

standard does not specify how it is to be doubled. 

With the doubling operation inconsistently specifi ed, implementations may not always perform in either 
correct or compatible ways; in fact we have seen software that does this incorrectly. Leaving point doubling 
unspecifi ed for certain points on elliptic curves would pose no problem if point doubling was not an integral 
part of ECC systems. Unfortunately, this is not the case. Multiplication of points by scalars is a crucial 
operation needed for elliptic curve Diffi e-Hellman (ECDH) key exchanges. ECDH key exchanges arc used 
to establish shared secret keys for encryption and authentication between two parties over an insecure chan- 
nel. The mechanism is explained in section 3. The problem is that all of the common algorithms for fi nding 
scalar multiples of a point involve doubling it and doubling points which arc generated as intermediate val- 
ues during the computation of the fi nal answer. This means that the problem may not be hedged by simply 
avoiding the use of certain forbidden points, as these points may be generated as intermediate results during 
a computation. Instead, we should prevent the use of curves containing such points, which is only slightly 
more diffi cult. 


3 Example Failed Key Exchange 

ECDH is an adaptation of the traditional Diffi e-Hellman key exchange using points on elliptic curves as the 
insecurely transmitted information. Each party generates a random scalar, k, and agrees on a set of elliptic 
curve domain parameters along with an initial point, P, on the chosen curve. Each party then uses P and its 
value of k to generate a new point Q = kP using scalar multiplication. These values of Q arc public keys, 
while the k values arc private keys. The Q values arc exchanged and each side multiples its received Q by 
its k to obtain the shared secret key S = kQ. 

For example, users i and j agree to use some curve with point P. They select k, and kj respectively 
and generate Q r = P and Qj = kjP , then transmit Q, and Qj over non-secured public channels. User i 
computes S = kjQ :i = kikjP and user j computes S = kjkiP. Scalar multiplication being commutitive, 

'Whether the basis is polynomial or normal is irrelevent for our purposes, the formula for doubling a point is the same. 
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these values of the shared secret key arc identical. Both users may then safely use S in symmetric key 
encryption algorithms, for example. 

The ECDH algorithm relies heavily on scalar multiplication of points. There arc several algorithms of 
varying effi ciency for computing this function. The simplest is merely to add P upon itself k — 1 times. For 
k > 1 however, this will involve doubling P as the initial step 2 . Many other more effi cient (and commonly 
implemented) methods also rely on doubling, including the binary method, the addition-subtraction method, 
the window method, and Lim and Lee’s Comb method (all these methods arc well described by Lopez 
and Dahab [LDOO]). More recent and even faster methods also rely on repeated doublings, and clearly do 
not avoid the problem we have described, if doubling certain points is undefi ned. All of the listed scalar 
multiplication algorithms simply assume a well-defi ned doubling algorithm. As we have shown, this is 
simply not the case for at least certain points on some curves. 

None of the standards documents that fail to include full doubling algorithms, specify amongst the re- 
quirements for acceptable curves that they do not contain any points that would violate their algorithms’ 
constraints on doubling. Thus naive implemented may allow such curves to be used, and if a point whose 
doubling is undefi ned is generated as an intermediate result in a scalar multiplication, bad things may hap- 
pen. If implemented arc not ECC experts and do not realize (0, 0) is the proper result of some doublings, 
they may consider the result incomputable and throw an exception or return an error value. This could ren- 
der an ECDH exchange a failure. In an implementation that ignores the restriction and attempts to double 
such points with an incomplete algorithm, the result can be a point not on the curve. This will clearly be 
troublesome and either lead to an error condition if checking is performed, or (as we shall demonstrate) 
inconsistent shared secret keys may be generated, making symmetric encryption and decryption operations 
unable to decode encoded data. These arc both problematic situations, which could have been avoided in 
the specifi cations. 

As an example of how doubling of an intermediate point not on the curve can lead to inconsistent keys, 
we present an example using the previously discussed curve over F p , with p = 23, a = 1, and 6 = 1. 
The point (4, 0) will be generated as an intermediate result of the addition-subtraction method of scalar 
multiplication, and a point not on the curve will be generated as the fi nal result due to the addition function 
attempting to compute the double of a point on the x-axis without the proper algorithm. 

Take the point P = (19, 18), which by equation 1 can be verifi ed as on the example curve. Multiply this 
point by the scalar k = 427. Following the addition-subtraction method, we fi rst convert 427 into its non- 
adjacent form (NAF), and initialize a return value Q to (0, 0). The chosen scalar multiplication algorithm 
then iterates through the values in the NAF form of k. For each entry in the NAF, Q is doubled, and if the 
entry is a 1, then the initial point (19, 18) is also added to Q, while if the entry is a -1, then the additive 
inverse of the initial point (19, —18) = (19, 5) is added to Q. 

We take the NAF of 427, u = [—1, 0, —1,0, —1, 0, —1, 0, 0, 1], and list out the intermediate values of 
Q = kP with respect to each NAF entry Subscripts referring to the elements of the NAF start with 0 as 
the rightmost element of u, increasing to the left. Our point addition algorithm is that listed by Lopez and 
Dahab [LDOO], which (incorrectly) specifi es no precondition that points not lie on the x-axis, and does not 
check for this condition as paid of the algorithm, and does not properly return (0, 0) in such cases. 


initialize 

- Q = (o,o) 

u[0] = 1 - 

-*■ Q = (19, 18) 

u[l] = 0 - 

■+ Q = (12, 19) 

u[ 2] = 0 - 

■+ Q = (5, 19) 


2 Using k £ {0, 1} makes no sense as the result will be (0, 0) or P, either of which an eavesdropper could identify from the 
domain parameters and deduce k. 
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u[ 3] = -1 
u[ 4] = 0 


Q = (11,3) 
Q = ( 4,0) 


Up to this point in the execution, there have not been any problems with doubling Q nor performing the 
subsequent possible addition of P or — P. All of the generated points have been on the curve. However, 
the latest value of Q generated is (4,0), which (while on the curve) lies on the x-axis. The next step 
of the algorithm, since there arc more elements of the NAF, is to double Q. Since neither the addition 
nor multiplication algorithms we arc using here make checks on Q before following the flawed doubling 
proceedure, it is interesting to see the result. 


u[5] = -1 - 

■+ Q = (15, 0) 

it [6] =0 - 

■+ Q = (16, 0) 

«[ H = -i - 

- Q = ( 14,0) 

it [8] = 0 - 

■+ Q = (18, 0) 

it [9] = -1 - 

+ Q = (21,22) 


Doubling (4,0) and adding — P to it gives (15,0), which from equation 1 does not lie on the curve 
specifi ed. Using this value of Q and fi nishing through the elements of the NAF of 427, the fi nal result 
returned by the scalar multiplication is (21, 22), which is also clearly not on the curve, as it does not satisfy 
equation 1. 

To see why this is a problem, consider the case where two parties decide to use an ECDH key exchange 
to establish a shared secret key for a session. They agree to use the example curve that we have discussed, 
and the point P = (19, 18). One of the parties draws k = 427 as its random bits. The point it generates as 
Q = kP will not lie on the selected curve. An error occurs in the exchange whether the generating party 
checks Q and decides it is invalid, or transmits it and lets the other party notice that it is invalid. The results 
arc worse yet if the other party receives the bogus Q and generates a session key from it. This key will be 
unusable as it is generated from a point that is not on the curve and the session keys generated by each party 
will not agree, preventing them from communicating. 

4 Avoidance 

Since on-axis points (which arc by some defi nitions undoublable) may be generated as intermediate results 
of scalar multiplication, avoiding the doubling problem is more diffi cult than simply not using such points. 
In an ECDH key exchange, if such a point is encountered and must be doubled during a scalar multiplication, 
it is also insuffi cient to merely start over using another multiplication algorithm, another k, or another set of 
curve parameters. Using another algorithm is a poor attempt at a solution, as even if the problem is avoided 
locally, there is generally no way to ensure the other party will not run into it. Using another value of k is 
also a bad idea, as the curve obviously contains troublesome points which may be encountered again, and 
generating more random bits for another k may be relatively expensive on some systems. Curve domain 
paramenters will have typically been agreed upon ahead of time and renegotiating them is likely to be a bad 
idea, as schemes that allow this will be open to many forms of attack. 

The most foolproof solution is to simply not allow curve domain parameters that specify curves with 
disallowed points under certain poorly-specifi ed doubling operations. This involves checking the domain 
parameters in the curve generating function over the elements of the underlying fi eld, F p or . For 
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instance, we could clearly and easily predict problems with F p , where p = 23, a = 1, and b = 1, by solving 
for x in equation 1 with y = 0, in the range 0 < x < 23, and seeing that x = 4 satisies the relation. In 
general, verifying that no disallowed doublings can occur may be accomplished via two means. The brute 
force approach is to iterate through the members of the underlying h eld, testing that no members allow the 
restricted coordinate to be zero. 

A more elegant approach would be to solve for the roots of the point generating functions (equations 1 
and 5) with the restricted variable set to 0 and the chosen domain parameters. If none of the roots arc 
members of the selected h eld, then the set of elliptic curve domain parameters is safe to use, otherwise it is 
not. For curves over F p , the roots of equation 8 arc used and for curves over F%m, equation 9 is used. 

x 3 + ax T b = 0 (8) 

y 2 = b (9) 

Equation 8 can be easily solved using the domain parameters a and b in the general proceedure for 
solving cubic equations. Since at least two of the obtained roots arc complex, if the other does not he in the 
prime h eld selected, then the domain parameters arc safe. Equation 9 is derived from equation 5 by setting 
x = 0. Obtaining a square root function for the appropriate basis in the underlying fi eld is all else needed 
for F-> m curves. 

As an example, take the curve over F p specih cd by p = 23, a = 1,6 = 4, which only differs from the 
curve we have already seen to be poor by the 6 parameter. We easily see that there arc no zeros of x 3 + x + 4 
in F 23 , and thus that the curve generated by those parameters is safe for use. This test would have easily 
caught the example curve we showed to be a bad choice with 6 = 1, as we would h nd a non-complex root 
of x 3 + x T 1 in F 23 at x = 4 using the cubic formula. 

5 Conclusion 

We have described a problem with the current specih cations for elliptic curve cryptography in that they do 
not disallow the use of curves containing points on the axes which may not be doublable using certain ECC 
specih cations. We have shown that the accidental use of such curves may lead to failed key exchanges, and 
be confusing to debug. We have outlined a simple means of verifying that a given set of domain parame- 
ters is safe with regards to this condition for curves over both F p and F^m . Adding this verih cation check 
to the process for selecting curves for cryptography will allow use of the current point addition and dou- 
bling algorithms and scalar multiplication algorithms (and running code) without modih cation, and prevent 
doubling-related problems from arising. Restricting the usable curve domain parameters in this way does 
not influence the degree of security provided by ECC techniques. Ideally, we would h x all insufh dent stan- 
dards documents to fully specify doubling, however we have no effective way of making previously written 
code compliant, and so must select curves so as to avoid possible problems. 
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